前面幾天，我們已經把 VoCare 從需求一路整理到系統架構。

目前已經確定：

• 要解決哪些問題
• 需要哪些核心功能
• 資料怎麼流
• 資料要怎麼保存
• 前後端怎麼透過 API 溝通

到了這裡，接下來就不只是「想怎麼做」，而是：

真的開始把系統做出來。

而從 Day 09 開始，我也會正式把 Codex 放進 VoCare 的開發流程裡。

不是直接叫 Codex「幫我做一個 VoCare」

一開始最容易做的事情，就是直接丟一句：

幫我做一個 AI 長者陪伴系統。

但這種指令其實太模糊了。

因為 Codex 並不知道：

VoCare 有哪些使用者？

Memory 要存什麼？

聊天和問卷資料要怎麼處理？

家屬端需要看到哪些資訊？

所以前面花時間整理需求、資料流、資料庫和 API，其實就是在替後面的 AI Coding 做準備。

比起叫 Codex 自己猜我們要做什麼，我們應該先把任務拆清楚。

先讓 Codex 理解整個專案

真正開始寫程式之前，我希望先讓 Codex了解目前的專案結構。

包含：

• 前端放在哪裡
• 後端放在哪裡
• 使用什麼框架
• 資料庫相關程式在哪裡
• 已經有哪些 API
• 哪些功能已經完成
• 哪些地方還沒有實作

這一步很重要。

因為如果 Codex 沒有先理解既有專案，很容易發生：

原本已經有一套架構，但它又重新做一套新的。

所以我的做法會是先讓 Codex：

閱讀專案 → 理解現有結構 → 再開始修改。

而不是一開始就要求它大量產生程式碼。

把大功能拆成小任務

例如 VoCare 有一個很大的功能叫做：

AI 個人化陪伴與記憶系統

如果直接把整個功能交給 Codex，範圍其實太大。

所以可以繼續往下拆成：

第一步：建立聊天 API

接著：

第二步：保存 Conversation 與 Message

再來：

第三步：聊天後萃取 Memory

然後：

第四步：回答前搜尋 Memory

最後才把它們組合成完整的聊天流程。

這樣每一次只處理一個明確問題，也比較容易知道是哪一個步驟出錯。

我希望 Codex 的工作流程

目前我希望 Codex 參與 VoCare 開發時，大致按照這個流程：

讀取需求
→ 查看現有程式碼
→ 找到需要修改的位置
→ 提出修改方式
→ 實作功能
→ 執行測試
→ 檢查結果
→ 再進入下一個功能

這和單純「請 AI 幫我寫一段 Code」其實不太一樣。

因為真正的專案開發不是每次都建立一個全新的檔案。

更多時候是：

理解原本的程式，再在正確的位置修改。

這也是我接下來想實際測試 Codex 的地方。

Codex 寫完，不代表功能就完成

另一個我會特別注意的事情是：

AI 產生程式碼，不代表程式碼一定是對的。

即使程式可以執行，也可能有：

• 資料結構不一致
• API 格式錯誤
• 重複建立功能
• 沒有處理例外狀況
• 修改到不應該修改的程式
• 和原本架構不相容

所以 Codex 的角色比較像是：

協助我加快開發速度。

而不是：

完全取代我決定系統怎麼設計。

需求、架構和最後的檢查，還是需要自己掌握。